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1.  Introduction 

A  safety  property  of  a  program  asserts  that  some  proscribed  "bad  thing"  does  not  occur  during 
execution.  To  prove  that  a  program  satisfies  a  safety  property,  one  typically  employs  an  invariant,  a 
characterization  of  current  (and  possibly  past)  program  states  that  is  not  invalidated  by  execution.  If 
an  invariant  /  holds  in  the  initial  state  of  the  program  and  I  =>Q  is  valid  for  some  Q,  then  -■  Q  cannot 
occur  during  execution.  Thus,  to  establish  that  a  program  satisfies  the  safety  property  asserting  that 
-1 Q  does  not  occur,  it  suffices  to  find  such  an  invariant  I. 

Timing  properties  are  safety  properties  where  the  "bad  thing"  involves  the  time  and  program 
state  at  the  instants  that  various  specified  control  points  in  a  program  become  active.'  Timing  proper¬ 
ties  can  restrict  externally  visible  events,  like  inputs  and  outputs,  as  well  as  things  that  are  internal  to 
a  program,  like  the  value  of  a  variable  or  the  time  that  a  particular  statement  starts  or  finishes.  For 
example,  in  a  process  control  system,  the  elapsed  time  between  a  stimulus  and  response  must  be 
bounded.  This  is  a  timing  property  where  the  "bad  thing”  is  defined  in  terms  of  the  time  that  passes 
after  one  control  point  becomes  active  until  some  other  control  point  does.  Timing  properties  con¬ 
cerning  internal  events  are  useful  in  reasoning  about  ordinary  concurrent  programs  that  exploit 
knowledge  of  statement  execution  times  to  coordinate  processes.  One  such  protocol — for  mutual 
exclusion — is  given  in  section  4. 

Because  timing  properties  are  safety  properties,  the  invariant-based  method  outlined  above  for 
reasoning  about  safety  properties  can  be  used  to  reason  about  timing  properties.  This  means  that  a 
programming  logic  L  to  verify  (ordinary)  safety  properties  can  form  the  basis  for  a  logic  L'  to  verify 
timing  properties.  It  suffices  that  in  L'  we  are  able  to 

(1)  specify  in  /  and  Q  information  about  the  times  at  which  events  of  interest  occur  and 

(2)  establish  that  program  execution  does  not  invalidate  such  an  /. 

Point  (1)  means  that  in  defining  L',  the  language  of  L  might  have  to  be  extended  so  that  it  becomes 
more  expressive.  Point  (2)  means  that  the  inferencing  apparatus  of  L  might  have  to  be  refined  so  that 
I  can  be  proved  an  invariant  for  a  program  whose  semantics  includes  information  about  execution 
timings. 

This  paper  describes  extensions  to  a  logic  of  proof  outlines  [Schneider  92]  to  enable  verification 
of  timing  properties  for  concurrent  programs.  The  approach  taken  is  the  one  just  outlined:  we  start 
with  a  logic  for  proving  ordinary  safety  properties,  augment  the  language  according  to  (1)  and  refine 
the  inference  rules  according  to  (2).  The  presentation  is  organized  as  follows.  In  section  2,  we 
describe  a  logic  of  proof  outlines.  Section  3  introduces  and  axiomatizes  a  new  type  of  atomic  action, 
called  a  real-time  acdon.  The  correctness  proof  for  a  mutual  exclusion  protocol  in  section  4  illus¬ 
trates  the  use  of  our  logic.  Related  work  and  some  unresolved  technical  is.sues  are  discussed  in  sec¬ 
tion  5. 

2.  Proof  Outlines 

In  order  to  reason  about  a  program,  we  must  be  able  to  define  sets  of  program  states  and  reason 
about  them.  First-order  predicate  logic  is  an  obvious  choice  for  this  task,  and  we  employ  the  usual 

'Infonnally,  the  active  control  points  at  any  instant  are  determined  by  the  values  of  the  program  counters  at  that  in¬ 
stant.  See  §2  for  a  more  formal  delation. 
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correspondence  between  the  formulas  of  the  logic  and  the  programming  language  of  interest — each 
variable  and  expression  of  the  programming  language  is  made  a  term  of  the  logic  and  each  Boolean 
expression  of  the  programming  language  is  made  a  predicate  of  the  logic.  It  will  be  convenient  to 
assume  that  predicates  and  terms  are  always  defined,  although  the  value  of  a  term  may  be  unspecified 
in  some  states.  For  example,  we  will  assume  that  the  term  xly  has  a- value  whatever  value  y  has,  but 
that  y  *(x/y)  need  not  equal  x  when  y  is  0  because  the  value  of  xly  is  unspecified  in  such  states. 

Predicates  and  function  symbols  for  the  programming  language’s  data  types  provide  a  way  to 
express  facts  about  program  variables  and  expressions.  The  state  of  a  program,  however,  also 
includes  information  that  tells  what  atomic  actions  might  be  executed  next.  For  representing  this 
control  information,  we  wiU  find  it  convenient  to  fix  some  predicate  symbols,  called  control  predi¬ 
cates,  and  give  axioms  to  ensure  that,  as  execution  proceeds,  changes  in  the  values  of  these 
correspond  to  changes  to  program  counters.  (An  alternative  representation  would  have  been  to  define 
a  "program  counter"  variable  and  a  data  type  for  the  values  it  can  assume.) 

2.1.  Control  Predicates 

A  program  consists  of  a  set  of  atomic  actions,  each  of  which  executes  as  a  single  indivisible 
state  transformation.  The  control  points  of  the  program  are  defined  by  these  atomic  actions.  Each 
atomic  action  has  distinct  entry  control  points  and  exit  control  points.  For  example,  the  atomic  action 
that  implements  skip  has  a  single  entry  control  point  and  a  single  exit  control  point;  the  test  for  an  if 
has  one  entry  control  point  and  one  exit  control  point  for  each  alternative.  Execution  of  an  atomic 
action  a  can  occur  only  when  an  entry  control  point  for  a  is  active.  Among  other  things,  execution 
causes  that  active  entry  control  point  to  become  inactive  and  an  exit  control  point  of  a  to  become 
active. 

For  each  statement  or  atomic  action  S,  we  define  the  following  control  predicates: 
at(,S):  an  entry  control  point  for  5  is  active. 

(rfter{S):  an  exit  control  point  from  5  is  active. 

The  various  statements  in  a  programming  language  give  rise  to  axioms  relating  these  control  predi¬ 
cates.  The  axioms  formalize  how  the  control  predicates  for  a  statement  or  atomic  action  S  relate  to 
the  control  predicates  for  constructs  comprising  S  and  constructs  containing  S,  based  on  the  control 
flow  defined  by  S.  For  a  guarded-command  programming  language  [Dijkstra  75),  these  axioms  are 
given  in  Figure  2.1.  We  use  GEval^fiS)  there  to  denote  the  guard  evalua’lon  action  for  an  if  and 
GEvaldoiS)  to  denote  the  guard  evaluation  action  for  a  do.  And,  we  w;ite  Pj  © P2  ®  ©  P„  to 

denote  that  exactly  one  of  P  \  through  P„  holds. 

2.2.  Syntax  and  Meaning  of  Proof  Outlines 

A  proof  outline  PO{S)  for  a  program  5  is  a  text  in  which  every  atomic  action  of  S  is  preceded 
and  followed  by  an  assertion  enclosed  in  braces  ("{"  and  Each  assertion  is  a  Predicate  Logic 
formula  in  which 

•  the  free  variables  are  program  variables  (typeset  in  italics)  or  rigid  variables,  (typeset  in  upper¬ 
case  roman),  and 

•  the  predicate  symbols  are  control  predicates  or  the  predicates  of  the  programming  language’s 
expressions. 
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Atomic  action:  For  S  a  skip,  guard  evaluation  action,  or  assignment: 

-1  (ar(5)  A  qfter(S)) 

Sequential  composition:  For  S  the  sequential  composition  SiSi- 

(a) ar(S)  =  ar(Si) 

(b)  (rfteriS)  =  afteriS2) 

(c) q/rer(5i)  =  at(S  2) 

if  Control  Axioms:  For  an  if  statement: 

■S:ifBi— 0  0  ■■■  D 

(a)  at(S)  =  atiGEval^S)) 

(b)  (rfter{S)  -  (afteriSx)  ©  afteriS2)  ®  •••  ®  (tfter(Sn)) 
{c)(rfteriGEval^S))  =  (ar(Si)  ©  a/(52)  ©  ...  ©  ar(S,)) 

do  Control  Axioms:  For  a  do  statement: 

S :  do  B I  S I  Q  82—^82  Q  D  S„  od 

(a)  at(GEvaltio(S))  =  (at(S)  ©  after{S\)  ©  qfier(S2)  ©  ...  ©  afteriS„)) 

(b)  after{GEval^(S))  =  (ar(5 ,)  ©  atiS2)  ©  . .  ®  atiS„)  ®  afier(S)) 

cobegin  Control  Axioms:  For  a  cobegin  statement: 

S:  cobegin  Si  //  S2  //  •  U  S„  coend 

(a)ar(S)  =  (ar(Si)  a  ...  a  ar(S„)) 

Q3)i^er(S)  =  (c^eriSi)  a  ...  a  c^eriSn)) 

_ Figure  2.1.  Control  Predicate  Axioms 


Assertions  in  which  all  tenns  are  constructed  from  program  variables,  rigid  variables,  and  predicates 
involving  those  variables  are  called  primitive  assertions.  An  example  of  a  proof  outline  appears  in 
Figure  2.2.  In  it,  x  is  a  program  variable  and  X  is  a  rigid  variable.  All  assertions  except  the  first  and 
last  are  primitive. 

The  assertion  that  immediately  precedes  a  statement  or  atomic  action  T  in  a  proof  outline  PO(S) 
is  called  the  precondition  of  T  and  is  denoted  pre(J)\  the  assertion  that  directly  follows  T  is  called  the 
postcondition  of  T  and  is  denoted  by  post(J).  For  the  proof  outline  in  Figure  2.2,  this  correspondence 
is  summarized  in  Figure  2.3.  Finally,  for  a  proof  outline  PO(,S),  we  write  pre{PO{S))  to  denote 
pre(S),  postiPOiS))  to  denote  postiS),  and  use  a  triple 

(2.1)  {/>}PO(S){(2} 

to  specify  the  proof  outline  in  which  pre(,S)  is  P,  postiS)  is  Q,  and  all  other  pre-  and  postconditions 
are  the  same  as  in  PO(S). 

A  proof  outline  PO(S)  can  be  regarded  as  associating  an  assertion  pre{T)  with  control  predicate 
adj)  and  an  assertion  post{T)  with  (rfteriT)  for  each  statement  T  in  a  program  fragment  S. 
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{;c=X  A  ar(5)} 

S:  ifar^O ->  {j:=X  A  j:>0} 

Si:  skip 
{j:=Xajc>0} 

D  j:<0-»  U=XAac<0} 

82'-  X  :=-x 

{-Jt=XA-X<0} 

fi 

[x=abs(X)  A  afier(S)} 

Figure  2.2.  Computing  abs(x) 


Assertion 

Assertion  Text 

pre(S) 

x=X  A  atiS) 

postiS) 

x=abs(X)  A  afteriS) 

pre(Si) 

x=X/\x>{) 

post(Si) 

X=X  AJt>0 

prelSi) 

x=X  Ax<0 

postiS  2) 

-x=X  A  -x<0 

Figure  2  J.  Assertions  in  a  Proof  Outline 


Consequently,  a  proof  outline  defines  a  mapping  from  each  control  point  \  of  a  program  to  a  set  of 
assertions — those  assertions  associated  with  control  predicates  that  are  true  whenever  X  is  active.  In 
most  cases,  a  control  point  is  mapped  to  a  single  assertion.  For  example,  the  proof  outline 

(2.2)  {P}  Si  {<21  52  {/?} 

maps  the  entry  control  point  for  program  Si  S2  to  the  single  assertion  P.  This  is  because  at(Sj)  and 
at(S  1  S2)  are  the  only  control  predicates  that  are  true  if  and  only  if  the  entry  control  point  for  S 1  S2  is 
active,  and  (2.2)  associates  F  with  both  of  these  control  predicates.  However,  a  proof  outline  can  map 
a  given  control  point  to  multiple  assertions.  An  example  of  this  appears  in  Figure  2.2.  There,  the  exit 
control  point  for  S 1  is  mapped  to  two  assertions — post(Si)  and  postiS) — because  whenever  the  exit 
control  point  of  S 1  is  active  both  ctfteiiS  1 )  and  qfter(,S)  are  true. 

The  assertions  in  a  proof  outline  are  intended  to  document  what  can  be  expected  to  hold  of  the 
program  state  as  execution  proceeds.  The  proof  outline  of  Figure  2.2,  for  example,  implies  that  if 
execution  is  started  at  the  beginning  of  S 1  with  x=23  (a  state  that  satisfies  pre{S  1 )),  then  if  S 1  com¬ 
pletes,  post(Si)  will  be  satisfied  by  the  resulting  program  state,  as  will  po5t(S).  And  if  execution  is 
started  at  the  beginning  of  S  with  x=X,  then  whatever  assertion  is  next  reached — be  it  pre(Si) 
because  X>0  or  preiSz)  because  X^O — that  assertion  will  hold  when  reached,  and  the  next  assertion 
will  hold  when  it  is  reached,  and  so  on. 

With  this  in  mind,  we  define  a  proof  outline  PO{S)  to  be  valid  if  it  describes  a  relationship 
among  the  program  variables  and  control  predicates  of  5  that  is  invariant  and,  therefore,  not  falsified 
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by  execution  of  S.  The  invariant  defined  by  a  proof  outline  PO(S)  is  "if  a  control  point  X  is  active, 
then  all  assertions  that  X  is  mapped  to  by  PO(S)  are  satisfied"  and  is  formalized  as  the  proof  outline 
invariant  for  POiS): 

(2.3)  Ipo(sy-  A  (iatiT)  =>  preiT))  a  {after{T)  =>  post(T))) 

T 

For  example,  the  proof  outline  invariant  defined  by  PO(S)  of  Figure  2.2  is 

ar(5)=>(x=X  A  a/(S))  a  (tfter(S)=^(x=abs(X)  Aqfter(S)) 

A  ar(5i)=>(x=XAX>0)  a  i^gr(Si)=^(x=XAX>0) 

A  at{S2)=>{x=XAX<Q)  A  <^er(S2)=>(-x=X A-x<0). 

Equating  proof  outline  validity  with  invariance  of  Ipots)  can  have  disturbing  consequences  for 
proof  outlines  that  map  a  single  control  point  to  multiple  assertions.  The  following  valid  proof  out¬ 
line  illustrates  this. 

(2.4)  [false] 

S:  if  true [false]  S':  x  :=  3  {j:=l)  fi 
{x=2] 

This  proof  outline  maps  the  exit  control  point  for  S'  to  two  assertions,  postlS')  and  post{S).  The 
proof  outline  is  valid  because  Ipo(S) 

at(S)  => false  a  efteriS)  =>  jc=2 
A  at(S')  false  a  afteriS')  ^  x=\ 

is  equivalent  to  false  (since  afteriS')-cfteriS)  is  valid)  and  therefore  lpo{S)  cannot  be  falsified  by  exe¬ 
cution  of  any  statement  The  problem  with  (2.4)  is  that  postiS),  the  assertion  associated  with  the  exit 
control  point  of  5,  is  not  implied  by  post(S'),  the  assertion  associated  with  the  exit  control  point  for 
the  last  atomic  action  in  S  (i.e  S').  As  a  result,  what  (2.4)  really  associates  with  the  exit  control  point 
for  5'  (viz.  pastes')  a  post(S))  is  not  accurately  characterized  by  post{S).  Given  a  valid  proof  outline 
PO(S),  it  seems  reasonable  to  expect  postiS)  to  hold  whenever  an  exit  control  point  of  S  is  active. 
Similarly,  pre^S)  should  be  constrained  so  that  if  it  holds  and  an  entry  control  point  of  S  is  active, 
then  assertions  that  POiS)  associates  with  that  entry  control  point  also  hold.  To  formalize  these  con¬ 
straints,  we  define  a  proof  outline  PO{S)  to  be  self  consistent  if  and  only  if 

(2.5)  at(S)  A  pre(S)  =*  IIpo(S) 

(2.6)  cfter(S)  a  Ilpots)  =>  post(.S) 
where 

Ifpo(sy-  A  ((0/(7)  =>  pre{T))  a  {afteriT)  =>post(T))) 

T*S 

f[po(s)  is  just  lpo(S)  with  the  two  conjuncts  concerning  pre(S)  and  post(S)  (i.e.  "at(S)=>pre(S)"  and 
''after(S)=>posteS)’')  omitted.^  Thus,  (2.5)  ensures  that  whenever  any  entry  control  point  X  for  S  is 
active,  if  pre(S)  holds  then  so  does  the  assertion  that  PO(S)  associates  with  X.  And  (2.6)  ensures  that 
whenever  any  exit  control  point  X  of  S  is  active,  if  the  assertion  associated  with  that  control  point 
holds  then  postiS)  will  hold  as  well.  Together,  (2.5)  and  (2.6)  mean  that  pre(S)  and  post(S)  consti¬ 
tute  a  reasonably  complete  interface  to  S:  provided  pre(S)  holds  when  execution  of  S  is  started,  the 
assertions  of  PO(,S)  will  characterize  any  states  that  arise  as  execution  proceeds  and  postiS)  will  hold 

V/  is  an  acronym  for  internal  invariant. 
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if  an  exit  control  point  for  S  is  ever  reached.  It  should  come  as  no  surprise  that  the  proof  outline  of 
(2.4)  is  not  self  consistent — (2.6)  is  violated. 

The  requirements  for  validity  of  a  proof  outline — invariance  of  Ipo{S)  and  self-consistency — can 
be  formalized  in  temis  of  !}{$  -validity  of  Temporal  Logic  formulas,  where  9{s  is  the  set  of  infinite 
state  sequences  that  model  execution  of  S  started  from  any  program  state  [Owicki-Lamport  82].  In 
this  formalization,  we  are  able  to  write  order  to  denote  that  a  Predicate  Logic  formula  P  is 

valid  because  every  program  state  is  the  first  state  of  some  interpretation  in  9{s  . 

(2.7)  Valid  Proof  Outline.  A  proof  outline  PO(S)  is  valid  if  and  only  if: 

Self  Consistency:  N(ar(5)  a  pre(S)  =>  Ilpo{S)) 

fHsHafieriS)  a  IIpo{S)  =>post(S)) 

Invariance:  !}is^iJpo(S)=^^ho(.s))  n 

Notice  that  according  to  Valid  Proof  Outline  (2.7),  rigid  variables  in  proof  outlines  can  be  used 
relate  the  values  of  program  variables  from  one  state  to  the  next.  This  is  because  free  rigid  variables 
in  a  temporal  logic  formula  are  implicitly  universally  quantified.  Thus,  Ipo{S)  ^ho{S)  is  -valid 
if  and  only  if  for  any  assignment  of  values  to  the  proof  outline’s  rigid  variables,  execution  of  S  starts 
in  a  state  that  does  not  satisfy  Ipo(S)  or  results  in  a  sequence  of  states  that  each  satisfy  Ipo{S)- 

For  example,  the  proof  outline  of  Figure  2.2  is  valid  and  contains  a  rigid  variable  X  to  record  the  ini¬ 
tial  value  of  X.  Starting  execution  in  a  state  where  at(S2)  and  x=-23  holds  will  satisfy 
ho(.s)=^^ho{S)  even  if  -23  is  not  assigned  to  X  because  then  Ipo(S)  'S  not  satisfied  (causing 
!po(S)=>OIpo(_s)  to  be  trivially  satisfied). 

2.3.  Axiomatization  for  a  Proof  Outline  Logic 

Proof  Outline  Logic  is  an  extension  of  Predicate  Logic.  The  language  of  Predicate  Logic  is 
extended  with  proof  outlines  for  all  atomic  actions,  statements,  and  programs.  The  axioms  and  infer¬ 
ence  rules  of  Predicate  Logic  are  extended  with  axioms  and  inference  rules  that  allow  only  valid 
proof  outlines  to  be  proved  theorems.  In  particular,  there  are  some  statement-independent  inference 
rules  as  well  as  an  axiom  or  inference  rule  for  each  type  of  statement  and  atomic  action. 

The  statement-independent  inference  rules  for  Proof  Outline  Logic  are  given  in  Figure  2.4. 
Rule  of  Consequence  allows  the  precondition  of  a  proof  outline  to  be  strengthened  and  the  postcondi¬ 
tion  to  be  weakened,  based  on  deductions  possible  in  Predicate  Logic.  Rule  of  Equivalence  allows 
assertions  anywhere  in  a  proof  outline  to  be  modified,  provided  a  self  consistent  proof  outline  having 
an  equivalent  proof  outline  invariant  results.  A  rigid  variable  can  be  renamed  or  instantiated  by  using 
the  Rigid  Variable  Rule;  PO(5)exp  in  the  conclusion  of  that  rule  denotes  a  proof  outline  in  which 
rigid  variable  X  in  every  assertion  is  replaced  by  Exp,  an  expression  involving  constants  and  rigid 
variables  (only).  Finally,  the  Conjunction  and  Disjunction  Rules  allow  two  proof  outlines  for  the 
same  program  to  be  combined.  POa(S)G POpiS)  is  used  to  denote  the  proof  outline  that  associates 
assertion  Acp/^Bcp  with  each  control  predicate  cp,  where  Xcp  is  the  assertion  that  POx(S)  associates 
with  control  predicate  cp:  POa(S)Q  POpiS)  denotes  the  proof  outline  that  associates  Aep  v  Bep  with 
each  control  predicate  cp 

We  now  turn  to  the  axiomatization  for  a  concurrent  programming  language.  The  skip  statement 
is  a  single  atomic  action  whose  execution  has  no  effect  on  any  program  variable. 
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Rule  of  Consequence: 


.  P'=^P,  {P}POiS){Q),  Q^Q' 


{/>'}  PO(S)  {Q'} 


Rule  of  Equivalence: 


PO(S),  Ipo(S)~ho\sy  PO'(S)  self  consistent 
PO\S) 


Rigid  Variable  Rule:  For  Exp  an  expression  involving  only  constants 
and  rigid  varibles: 

{P]PO(S){Q] 


[PLp]  PO(S)lLp  [QLp) 


Conjunction  Rule: 


POa(S),  POb(S) 
POa(S)QPOb(S) 


Disjunction  Rule: 


POa(S),  POb(S) 
POa(S)QPOb(S) 


Figure  2.4.  Proof  Outline  Logic:  Statement-independent  Rules 


skip  Axiom:  For  a  primitive  assertion  P:  [P )  skip  [P } 

The  assignment  statement  x  :=  £  is  also  a  single  atomic  action.  Its  execution  involves  evaluat¬ 
ing  E  and  then  storing  that  value  in  x? 

Assignment  Axiom:  For  a  primitive  assertion  P:  {Pf}  x:=e  {P} 


Sequential  composition  of  statements  is  denoted  by  juxtaposition  (without  the  traditional  semi¬ 
colon  separator). 


Statement  Composition  Rule: 


{P]PO(.Si)[Q],  {Q]POiS2){R] 
{P}PO(SO{Q}PO{S2)  [R] 


An  if  statement  consists  of  an  atomic  guard  evaluation  action  that  selects  for  execution  an  alter¬ 
native  whose  guard  is  true:  if  no  guard  is  true,  then  the  guard  evaluation  action  blocks.  We  use  the 
following  rule  for  reasoning  about  a  guard  evaluation  action. 


^For  simpUcity,  we  restrict  consideration  to  the  case  where  x  is  a  simple  identifier  and  not  an  array.  See  [Gries-Levin 
80]  for  the  more  general  rule. 
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GEvalifiS)  Axiom:  For  an  if  statement 

s:  ifBi^Si  D  ^2^52  a  •••  n  fi 

and  a  primitive  assertion  P: 

{/»}  GEvalifiS)  {/>  A((a/(5i)=>fi,)A...  A(ar(5„)=>B„))} 

A  proof  outline  for  an  if  is  then  constructed  by  combining  a  proof  outline  for  its  guard  evaluation 
action  with  a  proof  outline  for  each  alternative. 

xtRule:  id)  [P]GEvalfiS)[R], 

(b)  (/?Aa/(Si))=>/»i,  ...  iRA.atiSn))^Pn. 

(c)  {Fi}P<9(Si){<2},  {Pn)POiSn)[Q), 

[P) 

S:  if 

D 

D  B„  ^  [P„]  POiSn)  [Q] 

6 

[Q] 


Since  the  guard  evaluation  action  for  an  if  blocks  when  no  guard  is  true,  we  can  use  an  if  to 
implement  conditional  waiting.  For  example, 

if  fl  skip  fi 

blocks  until  the  program  state  satisfies  B. 

The  guard  evaluation  action  for  do  selects  a  statement  Si  for  which  corresponding  guard  B, 
holds  and  if  no  guard  is  true,  then  the  control  point  following  the  do  becomes  active. 

GEvaldoiS)  Axiom:  For  a  do  statement 

S.'doBi— ♦iS'i  0  B2  S  2  0  D  B„  S„  od 
and  a  primitive  assertion  P: 

{/>}  GEvaldoiS)  (B  A((ar(5,)=>B,)A  ...  a (ar(S„)=:>B„) 

/\iafteriS)^i->Bx  A,  ...  a-,B„)))} 

The  inference  rule  for  do  is  based  on  a  loop  invariant,  an  assertion  I  that  holds  before  and  after  every 
iteration  of  a  loop  and,  therefore,  is  guaranteed  to  hold  when  do  temri'-ates — no  matter  how  many 
iterations  occur. 

do  Rule:  (a)  {/)  G£val^(S)  {/?}, 

(b)  (/?  A or(5, ))=>£,,  ....  (/?Aar(5„))=>B„. 

(c)  {FilFOCSi)!/},  ....  {P„]POiS„)[n 

(d)  iR  r^trfteriS))  =>  (/ a^B,  a  ...  a-.B„) 

{/) 

5:  do  B,  [Pi]POiSi)  {/) 

D  ••• 

n  B„  -♦  {p„i  pois„)  {/} 

od 

{/  A— 1B1  A  ...  A— iB,l} 


The  inference  rule  for  a  cobegin  is  based  on  combining  proof  outlines  for  its  component 
processes.  An  interference-freedom  test  [Owicki-Gries  76]  ensures  that  execution  of  an  atomic  action 
in  one  process  does  not  invalidate  the  proof  outline  invari’nt  for  another.  This  interference-freedom 
test  is  formulated  in  terms  of  triples, 

NIi(X,A):  [pre(a)AA}  a  {A}, 

that  are  valid  if  and  only  if  a  does  not  invalidate  assertion  A.  If  no  assertion  in  PO(Si)  is  invalidated 
by  an  atomic  action  a  then,  by  definition,  Ipois^)  ^Iso  cannot  be  invalidated  by  a.  Therefore,  we  can 
prove  that  a  collection  of  proof  outlines  PO(Si), ...,  PO(5„)  are  interference  free  by  establishing: 

For  all  J,y,  l<i<n,  \<j<n,  i^j: 

For  all  atomic  actions  a  in  5,  : 

For  all  assertions  A  in  PO(Sj):  NI(a,  A)  is  valid. 

The  following  inference  rule  determines  when  a  valid  proof  outline  for  a  cobegin  will  result  from 
combining  valid  proof  outlines  for  its  component  processes: 

cobegin  Rule:  (a)  PO(S\),  •.  PO{Sn) 

(b)  P  ^pre(PO(Sx))A  ...  Apre(PO(S„)), 

(c)  post(PO(S  i))  A  ...  ApostiPO(S„))=>  Q, 

(d)  PO(Si),  ...,  POCSb)  are  interference  free. 

[P)  cobegin  PO(Si)  H  •"  H  PO(S„)  coend  {Q] 

Since  execution  of  an  atomic  action  a  in  one  process  never  interferes  with  a  control  pred’cate  cp 
in  another,  certain  interference-freedom  triples  follow  axiomatically. 

Process  Independence  Axiom:  For  a  control  predicate  cp  in  one  process  and  an  atomic 
action  a  in  another: 

[cp=C)  a{cp=C] 

Notice  that  N/(a,  cp)  follows  directly  from  this  axiom  when  a  and  cp  are  from  different  processes. 

2.4,  From  Proof  Outlines  to  Safety  Properties 

Theorems  of  Proof  Outline  Logic  can  be  used  to  verify  safety  properties  because  of  the  way 
proof  outline  validity  is  defined.  If  a  proof  outline  PO(.S)  is  valid  then  Ipo{S)  niust  be  an  invariant. 
And,  if  I poiS)  is  an  invariant,  then  according  to  the  me; hod  of  §1  for  proving  safety  properties  we  can 
prove  that  executions  of  S  starting  with  pre(POiS))  true  will  satisfy  the  safety  property  proscribing 
-I  Q.  We  simply  prove 

(2.8)  (cpAAcp)=>Q 

for  every  assertion  Aep  in  PO(S),  where  Aep  is  the  assertion  that  POfS)  associates  with  control  predi¬ 
cate  cp.  For  example,  we  prove  as  follows  that  for  the  absolute  value  program  in  Figure  2.2, 
afteriS)=^x=abs(X)  holds  during  executions  started  in  a  state  satisfying  atfS)  a  x=X:  First,  because 
post{S)=^x=abs(X)  is  valid,  for  the  case  where  cp  is  qfterfS),  (2.8),  which  is 

qfterfS)  a  postfS)  =>  {efterfS)  =>x=n65(X)), 
is  valid.  Second,  for  the  case  where  cp  is  not  implied  by  afterfS),  (2.8)  is  trivially  valid. 
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3.  Real-time  Actions 

We  must  know  something  about  the  execution  times  of  atomic  actions  in  order  to  reason  about 
timing  properties  of  programs.  Therefore,  for  each  unconditional  atomic  action'^  a  in  our  program¬ 
ming  language,  we  define  corresponding  real-time  actions  cit(6  £)  where  5  and  e  are  real-valued,  non¬ 
negative  constants.  Execution  of  a  real-time  action  a(5_£)  causes  the  same  indivisible  state  transfor¬ 
mation  as  a  does,  but  constrains  it  to  occur  at  some  instant  between  e  and  e-)-5  time  units  after  the 
entry  control  point  for  a[5,  £]  becomes  active. 

We  have  elected  to  characterize  the  execution  time  for  a  real-time  action  in  terms  of  two  param¬ 
eters  (5  and  e)  in  order  to  have  flexibility  in  modeling  various  execution  environments.  Parameter  e 
describes  the  fixed  execution  time  of  the  atomic  action  on  a  bare  machine;  5  models  execution  delays 
attributable  to  multiprogramming  and  other  resource  contention.  A  system  where  each  process  is 
assigned  its  own  processor  is  modeled  by  choosing  0  for  5;  a  system  where  processors  are  shared  is 
modeled  by  choosing  a  value  for  5  based  on  the  length  of  time  that  a  runnable  process  might  have  to 
wait  for  a  processor  to  become  available. 

3.1.  Reasoning  About  Real-time  Actions 

Execution  of  a  real-time  action  cqs,  e]  affects  the  program  variables  and  control  predicates  in  the 
same  ways  as  the  atomic  action  a  from  which  it  was  derived.  Therefore,  we  have  the  following  infer¬ 
ence  rule: 

Real-time  Action  Transformation:  For  a  an  unconditional  atomic  action,  P  and  Q  primitive 
assertions,  and  0<5  and  0<e: 

{/’lats.ei  {Q} 

To  reason  about  timing  properties,  additional  terms  must  be  added  the  assertion  language.  This 
is  because  the  method  of  §2.4  for  reasoning  about  safety  properties  can  only  be  used  to  prove  safety 
properties  for  which  the  negation  of  the  proscribed  -ifi  is  implied  by  each  of  a  proof  outline’s  asser¬ 
tions.  Timing  properties  concern  the  instants  at  which  control  predicates  become  active  and  so  we 
define  a  term  for  each  control  predicate  cp: 

{the  time  that  cp  last  became  true  or 
-«» if  cp  has  never  been  true 

We  also  define  a  new  real-valued  term  T  to  be  equal  to  the  current  time. 

Some  additional  axioms  and  inference  rule  allow  us  to  reason  about  formulas  of  our  more 
expressive  assertion  language.  First,  the  various  non-atomic  statements  of  our  programming 
language  give  rise  to  axioms  based  on  the  way  they  equate  their  components’  control  points.  For  our 
programming  language,  these  axioms  are  given  in  Figure  3.1.  Second,  there  are  some  language- 
independent  axioms.  In  these,  cp  and  cp'  can  denote  any  control  predicates,  including  those  not  asso¬ 
ciated  with  entry  or  exit  control  points  for  real-time  actions. 

*An  atomic  action  is  unconditional  if  it  is  executable  whenever  its  entry  control  point  becomes  active.  In  the  program¬ 
ming  notation  of  §2.3,  skip,  assignment,  and  the  guard  evaluation  action  for  do  are  unconditional.  The  guard  evaluation  for 
If  is  not  unconditional. 
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Sequential  Composition  Axioms:  For 5  the  sequential  composition  Si  Sz- 

(a) Ta/(S)  =  Tar(5i) 

(b) tqfter(S)  =  tqfteriSi) 

(c)  t<tfter{S  1 )  =  Tar(S  2) 

if  Axioms:  For  an  if  statement; 

SrifBi— >5)  Q  B2— >52D  *■'  D 

(a)  Tat(S)  =  tatiGEval ^S)) 

(b)  ttrfteriS)  =  max(Ta/rer(5i).  tafter(S2),  ■■■,  Wier(S„)) 

(c)  tctfteriPEval ij(S))  =  max(tar(Si),  Tai(S2).  -Ta/CSn)) 

do  Axioms:  For  a  do  statement: 

S ;  do  Bi— >Si  Q  B2  S2  D  ■*'  D  od 

(a)  tatiGEval^iS))  =  max(t<ir(S),  tc^eriS  1).  tctfter{S2), ...  Tq/lrer(S„)) 

(b)  tafter(GEvalao(S))  =  max(Ta/(5i),  tatiS2) . ^aKSnX  Ta/rer(S)) 

cobegin  Axioms:  For  a  cobegin  statement: 

S:  cobegin  Si  H  S2  H  •  H  Sn  coend 
(a)  tat(S)  -  Tar(Si)  =  •  •  •  =  tar(S„)) 

(Jo)  tafterCS)  =  max(ta/ter(S i), Ta/ter(S„)) 

_ Figure  3.1,  Tcp  Axioms _ 


(3.1)  Tcp^r 

(3.2)  (Tcp=-«)  =>-,cp 

(3.3)  For  a  real  time  action  ocfg^e]  with  label  S:  (a)  at(S)  =>  Tat(S)^‘T<Tat(S)+5+e 

(b)tat(S)^-oo  =>  Ta/rer(5)^Ta/(S)+5+e 

Axioms  (3.1)  and  (3.2)  follow  directly  from  the  definition  of  Tcp.  Axiom  (3.3)  captures  that  essence 
of  a  real-time  action — that  its  entry  control  point  cannot  stay  active  too  long.  This,  in  turn,  allows  us 
to  infer  that  a  control  point  is  not  active  by  using 

(3.4)  T>Ta/(5)-t-5+e  =>  -,at(S) 

because  from  (3.3a)  we  have; 

<i/(S)  =>  Tat(5)^'KTar(5)-»-5-he 
=  «  Predicate  Logic* 

at(S)  =>  ((Tat(S)^r)  A  cr^Tat(S)+5+E) 

=  «  Predicate  Logic* 

((Tar(5)>T)  V  ('r>Tar(S)-i-5+e))  =>  -nat(S) 

=  «Axiom  (3.1)* 

T>Ta/(S)+5+e  -iat(S) 
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The  effect  on  these  new  tenns  of  executing  atomic  actions  is  captured  by  the  following  axioms 
of  Proof  Outline  Logic.  First,  for  any  ordinary  or  real-time  atomic  action,  we  have: 

'[cp  Invariance:  {cp=CATcp=V}  5:  a  {{cp  =>C)  =>  (Tcp=V)} 

The  antecedent  in  the  postcondition  is  necessary  for  the  case  where  cp  is  afteriS),  since  executing  5 
does  change  the  value  of  (rfter{S). 

Next,  for  any  ordinary  atomic  action: 

Action- time  Axioms:  (a)  {K<T(jr(S))  S;a  {K<Ta/rer(S)) 

(b)  {K^T}  S:a  {K<rafteriS)] 

Action-time  Axiom  (a)  asserts  that  the  exit  control  point  for  S  becomes  active  after  any  of  its  entry 
control  points  last  became  active.  Action-time  Axiom  (b)  asserts  that  the  exit  control  point  of  S 
becomes  active  later  than  any  time  that  the  entry  control  point  for  S  was  last  active. 

For  a  real-time  action  a[5,£],  the  following  axiom  characterizes  how  execution  changes  T  and 
the  Tcp- terms. 

Real-time  Action  Axiom  {K<Tdr(5)}  5:ot(8  ej  {K-He<Tayrer(5)} 

This  axiom  is  analogous  to  Action-time  Axiom  (a),  except  now  the  postcondition  has  been 
strengthened  to  give  a  tighter  lower  bound  on  when  the  exit  control  point  for  S  first  becomes  active. 

Two  things  that  the  Real-time  Action  Axiom  does  not  say  are  worthy  of  note.  First,  this  axiom 
does  not  bound  the  interval  during  which  the  entry  control  point  for  S  is  active.  This  is  because  that 
bound  already  can  be  derived  using  axiom  (3.3a),  since  atiS)  holds  whenever  the  entry  control  point 
for  S  does.  Second,  one  might  expect  to  be  able  to  prove  the  following  triple — its  precondition  being 
similar  to  that  of  Action-time  Axiom  (b). 

(3.5)  {K^T}  S;(X(6.£i  {K-^e^T} 

Unfortunately,  (3.5)  is  not  sound.  Execution  of  S  started  in  a  state  such  that  Tar(a)<K<‘r  would 
satisfy  the  precondition  but  might  terminate  before  K+e.  For  example,  consider  an  execution  of 
a[o,2]  that  is  started  at  time  0.  Thus,  at  time  T=1  the  state  would  satisfy  K<Tfor  K=l,  and  so 
precondition  K<Twould  be  satisfied  by  that  state.  When  execution  of  ct^o,  2)  terminates — 2  units  after 
it  is  started — at  time  l'=2,  the  postcondition  K+e^T  is  1-h2^2,  which  is  false. 

Finally,  the  following  rule  allows  rigid  variables  to  be  instantiated  with  expressions  involving 
Tcp-terms.  (Rigid  Variable  Rule  only  allows  rigid  variables  to  be  instantiated  by  constants,  rigid  vari¬ 
ables,  or  expressions  constructed  from  these.) 

rcp-lnstantmon  a  (Tcf  =V)  (fjalg) 

This  rule  is  typically  used  along  with  one  of  the  Action-time  Axioms  or  the  Real-time  Action  Axiom. 
For  the  case  where  real-time  action  a  and  control  predicate  cp  are  in  different  processes,  the  first 
hypothesis  of  Tcp-Instantiation  is  automatically  satisfied,  as  the  following  proof  of 
{Tcp=V}  a  (tcp=V)  demonstrates. 

Process  Independence  Axiom: 

1.  {a/(p)=C}  a  {a/(p)=C} 
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Tcp  Invariance: 

2.  {a/(p)=C  A  Ta/(p)=V}  a  {(a/(p)=>C)=>(tflr(p)=V)} 

Conjunction  Rule  with  1  and  2; 

3.  {at(p)=CATar(p)=V)  a  {a/(P)=C  a  ((a/(p)=>C)  =>  (Tnr(p)=V))} 

4.  at(p)=C  A  ((a/(p)  =>  C)  (Tar(p)= V)) 

=>  «Predicate  Logic* 
ta/(P)=V 

Rule  of  Consequence  with  3  and  4: 

5.  {ar(p)=CAtar(p)=V}  a  {Tat(p)=Vl 

Rigid  Variable  Rule  with  5,  replacing  C  by  true  and  then  \)y  false: 

6.  {a/(P)  A  Tar(p)=V}  a  {Tar(p)=V} 

7.  {-.ar(p)ATa/(P)=V}  a  {tar(p)=V} 

Disjunction  Rule  with  6  and  7: 

8.  {(ar(P)v-.ar(p))ATnr(P)=V}  a  (Tar(p)=V) 

Equivalence  Rule  with  8: 

9.  {Tar(p)=V}  a  {ar(p)=V} 

Thus,  we  obtain  a  derived  rule  of  inference: 

Derived  ^cp-Instantiation:  If  atomic  action  a  and  control  predicate  cp  are  in  different 
processes: 

{P]o.{Q) 

{Plp)Oi[Qlp] 


3.2.  Interference  Freedom  Revisited 

When  the  execution  times  of  atomic  actions  are  bounded,  certain  forms  of  interference  cannot 
occur.  This  is  illustrated  by  the  proof  outline 

{a:=0) 

cobegin 

{x=0}  oc  Cc  :=a:+l)[o.2i  U=l} 

// 

{j:=0)  p:  <y  :=x+l>jo.ii  {y=l) 
coend 

U=1  Ay=l} 

which  is  valid  but  caimot  be  derived  using  the  cobegin  Rule  because  FO(a.)  and  PO(P)  are  not 
interference  free.  In  particular,  A7(a,  pre(p))  is  not  valid. 

M(a,pre(P)) 

=  {pr<;(a)  Aprg(p))  (*  :=x+l>(o.2j  {pre(p)) 

=  U=0)  <x  :=x+l>[o.2]  U=0} 

Using  operational  reasoning,  however,  it  is  not  difficult  to  argue  that  execution  of  a  cannot  invalidate 
pre(fi)  and  so  PO(a.)  and  PO(fi)  should  be  considered  interference  free.  This  is  because  according  to 
cobegin  Axiom  (b)  in  Figure  3.1  both  at(a)  and  <2r(P)  become  active  at  the  same  instant,  say  time  0. 
By  definition,  a  completes  at  time  2,  and  so  x  remains  0  until  this  time.  Real-time  action  p  completes 
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at  time  1  and,  therefore,  must  find  ac  to  be  0.  It  is  simply  not  possible  for  a  to  change  the  value  of  x 
while  nr(P)  is  active. 

Our  cobegin  Rule  is  based  on  a  form  of  interference  freedom  that  does  not  take  into  account 
execution-time  bounds  of  real-time  actions.  In  particular,  NIict,  A^p)  does  not  account  for  the  fact 
that  although  Acp  might  be  associated  with  an  active  control  point  cp  when  a  is  started,  if  A  is  the 
precondition  of  a  real-time  action  then  we  may  be  able  to  prove  that  cp  cannot  be  active  when  a  com¬ 
pletes.  The  remedy  is  to  refine  Nlia,  Acp)  taking  into  account  the  time  bounds  for  how  long  an  entry 
control  point  for  a  real-time  action  can  remain  active.  The  following  triple  accomplishes  this. 

NIrticx,  Acp):  [atia)  a preia)  a  cp  a  a  [cp  =>  Acp ) 

Returning  to  the  example  above,  we  have: 

/V/„(a,prc(p)) 

=  {ar(a)  A  prg(a)  A  ar(P)  A  prc(P)}  <x  :=jc+l)(o.  21  {flr(p)  =>prc(P)} 

=  {a/(a)  Aa/(p)  Ajc=0}  (x  :=a:-(-1)[o.21  {«t(P)=>x=0) 

And,  this  obligation  can  be  discharged  as  follows. 

Real-time  Action  Axiom: 

1.  {K<tar(a)}  oc  <x  :=x-t-l>(o,2i  {K-t-2<Ta/rcr(a)} 

Derived  tcp- Instantiation  with  1 : 

2.  {Tar(p)<Tar(a)}  a:  <x  :=x-h1)(o.2i  {^ar(P)+2<T^^rc/•(a)) 

Axiom  (3.1): 

3.  Tc5fifcr(a)ST 

Rule  of  Consequence  with  2  and  3: 

4.  {Ta/(P)<Tar(a)}  a:  (x  :=x+l>(o.2i  {Tar(p)-t-2<‘r} 

Axiom  (3.3a): 

5.  af(P)  =>  Tar(P)^T:STa/(P)-Hl 

Predicate  Logic: 

6.  ((Tar(p)-t-2<‘I)  A  (ar(P)=>Tar(P)^‘T<Tar(p)-(-l))=>-,ar(p) 

Rule  of  Consequence  with  4, 5,  and  6: 

7.  {tar(p)^Tar(a)}  a:  (x  :=x-H>[o,2i  {--a/CP)} 

Predicate  Logic  and  Ta/(a)=Tar(6)  from  cobegin  tcp  Axiom  (a): 

8.  pre(NIri(sx,  prc(p))  ta/(P)^Tar(a) 

9.  ak&)  =>  post{NIr,  (a,  pre  (P))) 

Rule  of  Consequence  with  7,  8,  and  9: 

10.  Af/rt(a,pre(P)) 

4.  Example:  A  Mutual  Exclusion  Protocol 

Knowledge  of  execution  times  can  be  exploited  to  synchronize  processes.  A  mutual  exclusion 
protocol  attributed  in  [Lamport  87]  to  Mike  Fischer  illustrates  this  point.  The  core  of  this  protocol 
appjears  in  Figure  4.1.  There,  c,  d,  c’  and  d'  are  real-time  actions.  Provided  the  parameters  of  these 
real-time  actions  satisfy 
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cobegin 

a:  if:ic=0  ->  ^:skipfi 
c:  (x  ;=  1>i5(c).£(c)i 
d:  <skip)(5(^).£(d)l 
e:  ifx=l  /:skipfi 
Critical  Section  1 

// 

a':  ifx=0  — »  d';  skip  fi 
c':  (x  :=2}is(c’).c(c')\ 
d':  <skip>f8(^').£(a')) 
e':  ifx=2  /':  skip  fi 
Critical  Section  2 

coend 

Figure  4.1.  Mutual  Exclusion  Protocol 


(4.1)  5(c')+e(c')<e(d) 

(4.2)  5(c)+e(c)<e(d') 

this  protocol  implements  mutual  exclusion  of  the  marked  critical  sections. 

Mutual  exclusion  of  (rfter(e)  and  afterie')  is  a  safety  property.  It  can  be  proved  by  constructing 
a  valid  proof  outline  in  which  post(e)=>—iqfter(,€')  and  postie')=>—>(tfterie).  A  standard  approach 
for  this  is  to  construct  a  valid  proof  outline  in  which  -i(po5r(c)  a  postie'))  is  valid.  It  is  thus  impos¬ 
sible  for  qfteiie)  a  qfier{e')  to  hold  because  that  would  imply  post(e)  a  postie'). 

A  proof  outline  for  one  process  is  given  in  Figure  4.2;  the  proof  outline  for  the  other  process  is 
symmetric,  with  "1"  everywhere  replaced  by  "2"  and  the  primed  labels  interchanged  with  unprimcd 
ones.  Notice  that  po5r(e)=»x=l  and  postie')  =^x =2.  Thus,  the  proof  outlines  satisfy  the  conditions 
just  outlined  for  ensuring  that  states  satisfying  qfterie)  a  etfterie')  cannot  occur. 

It  is  not  difficult  to  derive  the  proof  outline  of  figure  4.2  using  the  axiomatization  of  real-time 
actions  given  above.  The  proofs  of  {preic)]  c  [postie)]  and  [preid)}  d  [postid)}  are  the  most 
enlightening,  as  they  expose  the  role  of  assumptions  (4.1)  and  (4.2)  in  the  correctness  of  the  protocol. 
Here  is  the  proof  of  [preic)]  c  [postie)]: 

Assignment  Axiom: 

1.  [true]  c:(x  :=  1)[5(c),£(c))  {x=1) 

2.  jc  =  l 

=*  « Axiom  (3.1)» 

x  =  \  A  tatic')^'T 
=>  «assumption  (4.1))» 

x=l  A  Tar(c')+5(c')+e(c')-e(d)<T 
=>  ^Predicate  Logic* 
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{true) 

a:  ifx=0  — »  {tat(c')^‘T) 
b :  skip 
{Tar(c')^'Il 
fl  [tatic')^n) 
c:  (x  :=  1>(5<c),£(c)1 

{x  ^0  A  (at(c')  =>  ‘fat(c')+S(c')+e(c')-eid)  <  ^atid)) } 
d  :  <skip>[5(^),  £(</)] 

{j:^0  a  —\at(c')] 

ifjc=l  — »  {a:=l  A -(a/(c')) 

/;  skip 

{j:=1  a  -iaf(c')} 

fi  {jt=l  A -ia/(c')) 

Critical  Section  1 

Figure  4.2.  Proof  Outline  for  Mutual  Exclusion  Protocol 


Tar(c')+5(cO+e(c')-eW)<T 
Rule  of  Consequence  with  1  and  2; 

3.  [true]  c :  <x  :=  l>(S(c), e(c)i  {x?t0  a  ta/(c')+5(c')+e(c')-e(</) <‘2'} 

Action-time  Axiom  (b): 

4.  (K^T)  c;C*  •.=  1>[5(c).£(c)] 

Derived  Tcp-Instantiation  with  4; 

5.  {rat(,c')<r}  c:<x:=l>[6(c).e(c)i  [tatic')<t<rfteric)] 

Conjunction  Rule  with  3  and  5: 

6.  {tat(.c')^r} 

c:  <x  :=  l>i8(c).E(c)i 

A  Ta/(c')+8(c')+e(c')-£(<f)<‘7’A  tat(c')^‘tctfter{c)] 

7.  Taf(c0+5(c')+e(c')-e(^f)<'r  A  rat(,c')£‘f<rfter{c) 

«assumption  (4.1)  and  Tq^rer(c)=Tar(d))» 

Ta/(c')+6(c')+e(c')-e(d)  <  tatid) 

=>  «Predicate  Logic  » 

atic')  =>  tat(c')+5(c')+e(c')-e(^)  <  t<«(d) 

Rule  of  Consequence  with  6  and  7: 

8.  {Ta/(c')^‘7'}  c:<x  :=  l>[8(c).e(c))  {x;t0  a  (ar(c')=>Tat(c')+5(c')+e(c')-e(d)<Ta/(d))} 


And,  here  is  the  proof  of  {pre{d)]  d  {post(d)]. 


skip  Axiom: 

1.  </:<skip>[6(d).E(<i)i  {JCJiO} 

Real-time  Action  Axiom: 

2.  {K^Ta/(<i)}  i/:  <skip>[6(<i).£(d)]  {K-^e(rf)<T^^reK^)} 

Rigid  Variable  Rule  with  2.  instantiating  K  with  L-^5(c')+e(c')-e(^^)+K  where  0<  k: 

3.  {L-h5(c')+e(c')-eW+>c^Ta/(<i)} 
d :  <skip)[5(<i)_  £(d)] 

{ L  -H  5(c ') + e(c ')  -  e  W) + K+e(d)  <  ^afterid) ) 

Predicate  Logic,  since  0<k: 

4.  L+5(,c')+e(.c')-e(d)<fatid)  =>  L+Sic')+t{c')-eid)+K<‘tat(d) 

5.  L+d(c')+£ic')-£id)+K+e(d)<tafter(d)  =>  L+S(c')+£(c')<f(rfter(d) 

Rule  of  Consequence  with  3, 4,  and  5: 

6.  {L-H5(c')+e(c')-e(^f)<Tar(ii)} 
d :  <skip>[5(,i)_  £(<<)] 

{L+5(c')+e(c')  <  Mrfter{d) ) 

Derived  tcp-Instantiation,  replacing  L  by 

7.  {Tar(cO+5(c')+e(c')-e(ii)<Tar(i/)) 
d :  <skip>(8(^<),  £(4)] 

{ Tar(c')+5(c')+e(c')  <  ^ctfter{d)) 

8.  ^at{c')+Hc')-^£i(:')<‘fqfter{d) 

=*  «Axiom  (3.1)  applied  to  a//eKif)» 

Tar(c')+5(c')+e(c')  <  Tq^er(d)^T 
=*  ^theorem  (3.4)  applied  to  ar(c')»* 

-.a/(cO 

Rule  of  Consequence  with  7  and  8: 

9.  {Tar(c')+5(c')+e(c')-e(d)<Tart;d))  <f:  <skip>(6(d).£(d)]  {-iar(c')} 

Process  Independence  Axiom: 

10.  {-iar(c')}  rf:<skip)(8(d).e(d)l  (-•a/(c')l 

Disjunction  Rule  with  9  and  10: 

11.  {ar(c')=>Ta/(c')+5(c')+e(c')-e(d)<Tar(d))  d :  (skipjja^.^), £(,i))  (-.ar(c')} 

Conjunction  Rule  with  1  and  1 1 : 

12.  {x^O  A  {aKc')  =>  Tar(c')+5(c')+e(c')-e(<f)<Tar(d))} 
d :  <skip>[8(d).  £W)] 

{x^O  A-iar(c')} 

Notice  how  timing  information  is  used  in  step  7  to  infer  that  a  particular  control  point  cannot  be 
active. 
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5.  Discussion 


5.1.  Other  Work  based  on  Proof  Outlines 

It  is  instructive  to  compare  our  logic  with  that  of  [Shaw  89],  another  Hoare-style  logic  [Hoare 
69]  for  reasoning  about  execution  of  real-time  programs.  In  [Shaw  89],  the  passage  of  time  is 
modeled  by  augmenting  each  atomic  action  with  an  assignment  to  an  interval-valued  variable  RT  so 
that  RT  contains  lower  and  upper  bounds  for  the  program’s  elapsed  execution  time.  The  Statement 
Composition  Rule  and  the  Assignment  Axiom  are  then  used  to  derive  rules  for  reasoning  about  these 
augmented  atomic  actions.^  Our  logic  is  obtained  by  augmenting  the  assertion  language  (of  an  under¬ 
lying  logic  of  proof  outlines)  with  additional  terms  (tcp  and  7)  and  devising  new  axioms  for  reason¬ 
ing  about  these  terms.  We  are  not  able  to  derive  rules  for  real-time  actions  by  using  the  original  logic 
because  we  do  not  employ  assignment  statements  to  model  the  passage  of  time. 

Although  more  complex,  augmenting  the  axioms  rather  than  the  atomic  actions  has  led  us  to  a 
more  powerful  logic.  First,  having  the  Tcp-terms  allows  the  logic  to  be  more  expressive.  These  terms 
permit  the  definition  of  properties  involving  historical  information — information  that  is  not  part  of 
the  current  state  of  the  program.  Timing  properties  that  constrain  the  elapsed  time  between  events 
can  only  be  formulated  in  terms  of  such  historical  information.  The  logic  of  [Shaw  89]  has  no  way  to 
express  historical  information  and,  consequently,  can  be  employed  to  reason  about  only  certain  tim¬ 
ing  properties. 

Second,  our  axiomatization  allows  reasoning  about  programs  whose  timing  behavior  is  data- 
dependent.  The  logic  of  [Shaw  89]  does  not  permit  such  reasoning.  For  example,  because  of  the  way 
statement  composition  is  handled  in  (Shaw  89],  the  logic  produces  ovcrly-conscrvaiive  intervals  for 
time  bounds.  This  is  illustrated  by  the  following  program,  which  takes  exactly  10  time  units  to  exe¬ 
cute. 

if  fl  ->  skip(o,9]  Q  -nfl  ^  sklp(o,i|  fi 
if  skip[o.i|  Q  -ifl ->  skip[o,9i  fi 

This  fact  can  be  proved  in  our  logic;  the  logic  of  [Shaw  89]  can  prove  only  that  execution  requires 
between  2  and  1 8  time  units. 

A  Hoare-style  programming  logic  for  reasoning  about  real-time  is  also  discussed  in  [Hooman 
91].  That  work  is  largely  incomparable  to  ours.  First,  the  programming  language  axiomatized  in 
[Hooman  91]  is  different,  having  synchronous  message-passing  and  no  shared  variables.  This  is 
symptomatic  of  a  fundamental  difference  in  the  two  approaches.  The  emphasis  in  [Hooman  91]  is  on 
the  design  of  compositional  proof  systems.  Shared  variables  cannot  (at  present)  be  handled  composi- 
tionally  and  so  they  are  excluded  from  programs.  In  contrast,  we  do  not  require  that  our  proof  system 
be  compositional.^  Relaxing  this  compositionality  requirement  means  that  it  is  not  difficult  to  extend 
our  logic  for  reasoning  (non-compositionally)  about  programs  that  employ  synchronous  message¬ 
passing  or  any  of  the  other  communication/synchronization  mechanisms  for  which  Hoare-style 
axioms  have  been  proposed. 


’The  idea  of  augmenting  actions  with  assignment  statements  in  order  to  reason  about  the  passage  of  time  is  discussed 
in  [Haase  81],  where  it  is  used  to  extend  Dijkstra's  wp  [Dijkstra  75]  for  reasoning  about  elapsed  execution  time. 

^The  cobegin  Rule  of  Proof  Outline  Logic  is  rtot  compositional  because  its  interference -freedom  lest  depends  on  the 
internal  structure  of  the  processes  being  composed. 
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The  types  of  properties  handled  in  [Hooman  91)  is  also  incomparable  to  what  can  be  proved 
using  our  logic.  Timing  properties  make  visible  the  times  at  which  control  points  become  active 
through  Tcp-terms.  A  compositional  proof  system  caiuiot  include  information  about  control  points  in 
its  formulas  because  they  betray  the  internal  structure  of  a  component.  The  logic  of  [Hooman  91], 
therefore,  may  only  be  concerned  with  the  times  at  which  externally  visible  events  occur:  the  time  of 
communications  events  and  the  time  that  program  execution  starts  and  terminates.  This  turns  out  to 
allow  proofs  of  certain  liveness  properties  as  well  as  certain  safety  properties.  Our  logic  cannot  be 
used  to  prove  any  liveness  properties. 

5.2.  Incompleteness  Concerns 

A  soundness  proof  for  the  logic  of  this  paper  will  appear  elsewhere.  The  issue  of  completeness, 
however,  is  a  bit  problematic.  The  following  proof  outline  illustrates  the  difficulties.  It  is  valid,  but 
is  not  provable  with  our  logic. 

(5.1)  {‘r=0}  a:skip(o.2i  {T=2}  b:  skip, 0.21  {^=4} 

A  related  proof  outline  is  provable: 

(5.2)  (0<Ta/(a)<T<2}  a:skip[o.2i  {2<T<2r(b)<TS4}  6:  skip(o,2]  (4<Ta/rer(b)<'7} 

Notice  that  the  assertions  of  (5.2)  characterize  system  states  that  would  exist  "during"  the  execution 
of  a  and  b\  the  assertions  of  (5. 1)  do  not. 

A  deficiency  in  our  logic  is  one  explanation  for  this  situation;  a  deficiency  in  the  definition  of 
proof  outline  validity  is  another.  Proof  outline  validity  is  defined  in  terms  of  a  set  {!Hs)  of  infinite 
state  sequences  that  model  execution  of  S  started  from  any  program  state.  This  set  contains  no 
sequence  whose  successive  states  differ  only  in  their  values  of  %  the  states  that  assertions  in  (5.2) 
characterize  and  those  in  (5.1)  do  not.  Certainly  such  states  exist  during  program  execution;  we  have 
simply  chosen  to  define  ^  so  that  states  are  recorded  only  when  the  value  of  some  Tcp-teim 
changes.  Now  consider  a  set  that  does  contain  sequences  having  such  temporal  interpolation 
states.  If  we  replace  in  Valid  Proof  Outline  (2.7)  by  then  (5.2)  remains  valid  and  (5.1) 
becomes  invalid.  The  incompleteness  problem  is  gone. 

There  are  also  other  reasons  to  prefer  in  defining  proof  outline  validity.  Invariance  under 
temporal  interpolation  seems  to  be  the  real-time  analog  of  invariance  under  stuttering,  something  that 
is  critical  when  proving  that  one  specification  or  a  program  implements  another.  Unfortunately,  the 
logic  of  this  paper  is  unsound  when  is  used  in  place  of  The  existence  of  temporal  interpo¬ 
lation  states  causes  a  new  form  of  interference.  This  interference  is  easily  dealt  with  by  extending  the 
definition  of  interference  freedom. 

Another  concern  when  designing  a  logic  is  expressive  completeness.  Timing  properties  include 
many,  but  not  all,  safety  properties  of  concern  when  reasoning  about  the  behavior  of  real-time  pro¬ 
grams.  This  is  because  the  historical  information  in  a  timing  property  is  limited  to  times  that  control 
points  become  active.  One  might  also  be  concerned  with  the  elapsed  time  since  the  program  vari¬ 
ables  last  satisfied  a  given  predicate  or  with  satisfying  constraints  about  how  the  program  variables 
change  as  a  function  of  time.  Both  are  safety  properties  but  neither  is  a  timing  property  (according  to 
our  definition  in  §1).  In  general,  safety  properties  can  be  partitioned  into  invariance  properties  and 
history  properties.  The  invariant  used  in  proving  an  invariance  property  need  only  refer  to  the  current 
state;  the  invariant  used  in  proving  a  history  property  may  need  to  refer  to  the  sequence  of  states  up  to 
the  current  state.  Timing  properties  are  a  type  of  history  property. 
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A  version  of  Proof  Outline  Logic  does  exist  for  reasoning  about  history  properties  [Schneider 
92].  It  extends  ordinary  Proof  Outline  Logic  by  augmenting  the  assertion  language  with  a  "past  state" 
operator  and  a  function-definition  facility.  In  this  logic,  our  Tcp-terms  can  be  constructed  explicitly; 
they  need  not  be  primitive.  And,  the  more  general  class  of  safety  properties  involving  times — be  it 
times  that  ptedicates  hold  or  times  that  control  predicates  hold — can  be  handled. 
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